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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a TS-family covering the 3^^ Generation Partnership Project: Technical Specification 
Group Services and System Aspects; Telecommunication management, as identified below: 

TS 32.432: 'Performance measurement; File format definition"; 

TS 32.435: "Performance measurement; extensible Markup Language (XML) file format definition"; 

TS 32.436: "Performance measurement; Abstract Syntax Notation 1 (ASN.l) file format definition". 

The present document is part of a set of specifications, which describe the requirements and information model 
necessary for the standardised Operation, Administration and Maintenance (OA&M) of a multi-vendor 3G PLMN. 

During the lifetime of a PLMN, its logical and physical configuration will undergo changes of varying degrees and 
frequencies in order to optimise the utilisation of the network resources. These changes will be executed through 
network configuration management activities and/or network engineering, see 3GPP TS 32.600 [4]. 

Many of the activities involved in the daily operation and future network planning of a PLMN network require data on 
which to base decisions. This data refers to the load carried by the network and the grade of service offered. In order to 
produce this data performance measurements are executed in the NEs, which comprise the network. The data can then 
be transferred to an external system, e.g. an Operations System (OS) in TMN terminology, for further evaluation. The 
purpose of the present document and the other related 3GPP TSs listed above is to describe the mechanisms involved in 
the collection of the data. 
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Scope 



The present document describes the general semantics of performance measurement resuk and collection. It defines the 
report file format, report file conventions and the file transfer procedure. Clause 4 specifies the file format for the bulk 
transfer of performance measurement results to the NM, while clause 6 discusses the file transfer procedure utilised on 
that interface. 

The present document does not give the definition of any specific file format - such as XML and ASN.l, which will be 
given in Performance Measurement extensible Markup Language (XML) File Format Definition 3 GPP TS 32.435 and 
Performance Measurement Abstract Syntax Notation 1 (ASN.l) File Format Definition 3GPP TS 32.436. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.401: "Telecommunication management; Performance Management (PM); Concept 

and requirements". 

[4] 3GPP TS 32.600: "Telecommunication management; Configuration Management (CM); Concept 

and high-level requirements". 

[5] 3GPP TS 25.442: "UTRAN Implementation Specific O&M Transport". 

[6] 3GPP TS 32.300: "Telecommunication management; Configuration Management (CM); Name 

convention for Managed Objects". 

[7] 3GPP TS 52.402: "Telecommunication management; Performance Management (PM); 

Performance measurements - GSM". 

[8] 3GPP TS 32.403: "Telecommunication management; Performance Management (PM); 

Performance measurements - UMTS and combined UMTS/GSM". 

[9] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[10] ITU-T Recommendation X.680: "Information technology - Abstract Syntax Notation One 

(ASN.l): Specification of basic notation". 

[II] ISO8601 : 2000(E) Data elements and interchange formats - Information interchange - 
Representation of dates and times". 



ETSI 



3GPP TS 32.432 version 10.1.0 Release 10 6 ETSI TS 132 432 VI 0.1.0 (2011-05) 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

network Element Manager (EM): provides a package of end-user functions for management of a set of closely related 
types of Network Elements. These functions can be divided into two main categories: 

- Element Management Functions for management of Network Elements on an individual basis. These are 
basically the same functions as supported by the corresponding local terminals. 

Sub-Network Management Functions that are related to a network model for a set of Network Elements 
constituting a clearly defined sub-network, which may include relations between the Network Elements. This 
model enables additional functions on the sub-network level (typically in the areas of network topology 
presentation, alarm correlation, service impact analysis and circuit provisioning). 

Network Manager (NM): provides a package of end-user functions with the responsibility for the management of a 
network, mainly as supported by the EM(s) but it may also involve direct access to the Network Elements. All 
communication with the network is based on open and well- standardised interfaces supporting management of multi- 
vendor and multi-technology Network Elements. 

Operations System (OS): generic management system, independent of its location level within the management 
hierarchy. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3G 3'^ Generation 

EM Element Manager 

GSM Global System for Mobile communications 

NE Network Element 

NM Network Manager 

PM Performance Management 



IVIeasurement Report File Format 



This clause describes the format of measurement result files that can be transferred from the network (NEs or EM) to 

the NM. 

The following conditions have been considered in defining this file format: 

• Since the files are transferred via a machine-machine interface, the files applying the format definitions should 
be machine-readable using standard tools. 



• 



The file format should be independent of the data transfer protocol used to carry the file from one system to 
another. 



• The file format should be generic across 3G systems. 

• The file format should be flexible enough to include all possible measurement types, i.e. those specified within 
clause 6 as well as measurements defined within other standards bodies, or vendor specific measurement types. 

• The file format should not impose any dependency between granularity periods for the generation of 
measurement results and file upload cycles for the file transfer from the network to the NM. 

• The file format should be flexible enough to support both the NE-based and the EM-based approaches, as 
discussed in Chapter 5, clause 5.1.1 of the present document. 
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• The file format should be usable for other interfaces than Itf-N if required. The measurement file header could be 
augmented to indicate this other usage, however this would be a non-standard extension. In the ASN.l (see ITU- 
T Recommendation X.680 [10]) file format definition this is accommodated by the use of the ellipsis notation. 
XML schema allows such additions through insertion of extra schema elements through the provider of the 
non-standard extension. 
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4.1 File Content description 

Table 4.1 lists all the file content items. It also provides an explanation of the individual items. 



Table 4.1 File Content Description 



File Content Item 




measDataCollection 


This is the top-level tag, which identifies the file as a collection of measurement data. The file 
content is made up of a header ("measFileHeader"), the collection of measurement result items 
("measData"), and a measurement file footer ("measFileFooter"). 


measFileHeader 


This is the measurement result file header to be inserted in each file. It includes a version 
indicator, the name, type and vendor name of the sending network node, and a time stamp 
("collectionBeginTime"). 


measData 


The "measData" construct represents the sequence of zero or more measurement result items 
contained in the file. It can be empty in case no measurement data can be provided. The 
individual "measData" elements can appear in any order. 

Each "measData" element contains the name of the NE ("nEld") and the list of measurement 
results pertaining to that NE ("measlnfo"). 


measFileFooter 


The measurement result file footer to be inserted in each file. It includes a time stamp, which 
refers to the end of the overall measurement collection interval that is covered by the collected 
measurement results being stored in this file. 


fileFormatVersion 


This parameter identifies the file format version applied by the sender. The format version defined 

in the present document shall be the abridged number and version of this 3GPP document (see 

below). 

The abridged number and version of a 3GPP document is constructed from its version specific full 

reference "3GPP [...] (yyyy-mm)" by: 

- removing the leading "3GPP TS" 

- removing everything including and after the version third digit, representing editorial only 
changes, together with its preceding dot character 

- from the resulting string, removing leading and trailing white space, replacing every multi 
character white space by a single space character and changing the case of all characters to 
uppercase. 


senderName 


The senderName uniquely identifies the NE or EM that assembled this measurement file by its 
Distinguished Name (DN), according to the definitions in 3GPP TS 32.300 [6]. In the case of the 
NE-based approach, it is identical to the sender's "nEDistinguishedName". 


senderType 


This is a user configurable identifier of the type of network node that generated the file, e.g. 
NodeB, EM, SGSN. The string may be empty (i.e. string size =0) in case the "senderType" is not 
configured in the sender. 


vendorName 


The "vendorName" identifies the vendor of the equipment that provided the measurement file. The 
string may be empty (i.e. string size =0) if the "vendorName" is not configured in the sender. 


collectionBeginTime 


The "collectionBeginTime" is a time stamp that refers to the start of the first measurement 
collection interval (granularity period) that is covered by the collected measurement results that 
are stored in this file. 


neld 


The unique identification of the NE in the system. It includes the user name ("nEUserName"), the 
distinguished name ("nEDistinguishedName") and the software version ("nESoftwareVersion") of 
the NE. 


neUserName 


This is the user definable name ("userLabel") defined for the NE in 3GPP TS 32.622 [9]. The 
string may be empty (i.e. string size =0) if the "nEUserName" is not configured in the CM 
applications. 


neDistinguishedName 


This is the Distinguished Name (DN) defined for the NE in 3GPP TS 32.300 [6]. It is unique across 
an operator's 3G network. The string may be empty (i.e. string size =0) if the 
"nEDistinguishedName" is not configured in the CM applications. 


neSoftware Version 


This is the software version ("swVersion") defined for the NE in 3GPP TS 32.622 [9]. 
This is an optional parameter which allows post-processing systems to take care of vendor 
specific measurements modified between software versions. 


measlnfo 


The sequence of measurements, values and related information. It includes a list of measurement 
types ("measTypes") and the corresponding results ("meas Values"), together with the time stamp 
("measTimeStamp") and granularity period ("granularityPeriod") pertaining to these 
measurements. 


measlnfold 


This attribute associates a tag name with the set of measurements defined by a measlnfo 
property. This is an optional parameter that may be used to assign unique names to categories of 
measurements grouped together by measlnfo elements. It allows parsing tools to easily isolate 
measurement sets by name. 


measTimeStamp 


Time stamp referring to the end of the granularity period. 


jobid 


The "jobId" represents the job with which measurement result contained in the file is associated. 
The "jobId" is mandatory when PMIRP is supported. 
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File Content Item 


Description 


granularityPeriod 


Granularity period of the measurement(s) in seconds. 


reportingPeriod 


Reporting period of the measurement(s) in seconds. 

The "reportingPeriod" is mandatory when PIVIIRP is supported. 


measTypes 


This is the list of measurement types for which the following, analogous list of measurement 
values ("measValues") pertains. The GSM only measurement types are defined in TS 52.402 [7]. 
The measurement types for UMTS and combined UMTS/GSM implementations are specified in 
TS 32.403 [8]. 


measValues 


This parameter contains the list of measurement results for the resource being measured, e.g. 
trunk, cell. It includes an identifier of the resource ("measObjInstId"), the list of measurement result 
values ("measResults") and a flag that indicates whether the data is reliable ("suspectFlag"). 


measObjInstId 


The "measObjInstId" field contains the local distinguished name (LDN) of the measured object 
within the scope defined by the "nEDistinguishedName" (see 3GPP TS 32.300 [6]). The 
concatenation of the "nEDistinguishedName" and the "measObjInstId" yields the DN of the 
measured object. The "measObjInstId" is therefore empty if the "nEDistinguishedName" already 
specifies completely the DN of the measured object, which is the case for all measurements 
specified on NE level. For example, if the measured object is a "ManagedElement" representing 
RNC "RNC-Gbg-1", then the "nEDistinguishedName" will be for instance 

"DC=a1 .companyNN.com, SubNetwork=1 ,IRPAgent=1 ,SubNetwork=CountryNN,MeContext=MEC- 
Gbg-1 ,ManagedElement=RNC-Gbg-1 ", and the "measObjInstId" will be empty. On the other hand, 
if the measured object is a "UtranCell" representing cell "Gbg-997" managed by that RNC, then 
the "nEDistinguishedName" will be for instance the same as above, i.e. 

"DC=a1 .companyNN.com,SubNetwork=1 ,IRPAgent=1 ,SubNetwork=CountryNN,MeContext=MEC- 
Gbg-1,ManagedElement=RNC-Gbg-1", and the "measObjInstId" will be for instance 
"RncFunction=RF-1 ,UtranCell=Gbg-997". The class of the "measObjInstId" is defined in item F of 
each measurement definition template. 


measResults 


This parameter contains the sequence of result values for the observed measurement types. The 
"measResults" sequence shall have the same number of elements, which follow the same order 
as the measTypes sequence. Normal values are INTEGERS and REALs. The NULL value is 
reserved to indicate that the measurement item is not applicable or could not be retrieved for the 
object instance. 


suspectFlag 


Used as an indication of quality of the scanned data. FALSE in the case of reliable data, TRUE if 
not reliable. The default value is "FALSE", in case the suspect flag has its default value it may be 
omitted. 


timestamp 


This tag carries the time stamp that refers to the end of the measurement collection interval 
(granularity period) that is covered by the collected measurement results that are stored in this file. 
The minimum required information within timestamp is year, month, day, hour, minute, and 
second. 



The measlnfo contains the sequence of measurements, values and related information, in a table-oriented structure. 
A graphical representation of this structure can be found in clause 6.1. 

The representation of all timestamps in PM files shall follow the representations allowed by the ISO 8601 [11]. 
The precise format for timestamp representation shall be determined by the technology used for encoding the PM file 
(e.g. ASN.l, XML DTD, XML Schema). The choice of technology should ensure that this representation is derived 
from ISO 8601 [11]. Based on the representation used, the timestamp shall refer to either UTC time or local time or 
local time with offset from UTC. 

At least for those measurement types that are re-used from non-3GPP standards (e.g. IP, ATM), it is required that the 
measType be operator definable. This is necessary to allow the operator to harmonise the numbering between different 
vendors' systems where appropriate. Through this harmonisation, it can be assured that identical measurements always 
carry the same measType value, which is required by the post-processing system. This requirement will eventually be 
reflected in TS 52.402 [7] and TS 32.403 [8], which specify the performance measurements for GSM (TS 52.402 [7]) 
and UMTS and combined UMTS/GSM systems (TS 32.403 [8]). 
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5 Measurement Report File Conventions and Transfer 

Procedure 

This clause describes the conventions how files containing performance measurement results are generated in the 
network (EM or NEs) and the procedure to transfer these files from the network to the NM. 

5.1 Conventions 

The following clauses define conventions for the generation and the naming of measurement-result files. 

5.1.1 File generation 

Since vendors may choose to implement the NM interface either in the NEs or the EM, the measurement result files for 
collection by the NM (push or pull transfer mechanism) may be provided by the NEs or the EM. Note that within one 
3G network both possibilities may occur, since NEs of different types may use either one of the two possible 
approaches (NE based or EM based). This is particularly true in a multi- vendor network. 

The procedures for the transfer of the files to the NM from either the NE or the EM are described in clause 5.2. 

5.1 .1 .1 NE based approach 

The NE shall generate one measurement report(measurement record) immediately at the end of each granularity period. 
This measurement report shall contain all measurement results produced by the NE within that granularity period. For 
example, if a NodeB runs 10 measurements with a granularity period of 15 minutes and 5 measurements with a 
granularity period of 5 minutes, then it shall generate one measurement report containing 10 results every 15 minutes, 
and one measurement reportcontaining 5 measurement results every 5 minutes. 

In the event of two or more granularity periods coming to an end at the same time, the NE shall generate one 
measurement report per granularity period. Hence in the above example, the NodeB shall generate 2 measurement 
reports - one containing 10 results (15min granularity period) and the other containing 5 measurement results (5 min 
granularity period), when the end time of the granularity periods coincide. 

Measurement reports (measurement record) of a particular granularity period are assembled into measurement result 
file for transfer, e.g. from the NE or EM. The number of measurement reports assembled is based on reporting 
period. The different types of measurement result file that can be supported are in section 5.1.2. 

The NE shall be identified both in the file name and in the file contents. NE identifiers (names) used for the files shall 
be in accordance with the NE naming conventions defined in 3GPP TS 32.300 [6]. The file shall be available for 
transfer as soon as all applicable results have been assembled. 

Each NE is responsible for the generation and maintenance of the measurement reports (measurement record) 
pertaining to its own measurements (i.e. the measurements it executes). In particular, this implies that the RNC is not 
involved in the generation, provision or transfer of measurement result files of its controlled NodeB s, i.e. for the 
measurements defined for the NodeB in the present document, no results will be sent via the lub interface. (Note that 
NodeB measurement results may be routed across the same physical interface as lub, see 3GPP TS 25.442 [5] for 
details). 

5.1 .1 .2 EM based approach 

This approach requires that measurement results be forwarded to the EM according to the mechanisms described in 
clause 4.2.4 of the 3GPP TS 32.401 [3]. The EM may choose to provide measurement result files as described above for 
the NEs, however, additional flexibility may be offered. For example, measurement results from several granularity 
periods and/ or several NEs could be written into one single file. These NEs may be determined based on network 
hierarchy (e.g. all NodeB s controlled by the same RNC, all NEs controlled by the same EM), or management domains 
configured by the system operator (e.g. NodeB s belonging to a certain (management or geographical) area). In case 
such rules are applied by the EM for the routing of measurement results to specific files then they shall be operator 
configurable. If results from more than one NE are contained in a file, the NE identifier used for the file shall be the EM 
name as defined in 3GPP TS 32.300 [6], or a domain name configured by the system operator. If results from more than 
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one granularity period are contained in the file then the beginning of the first and the end of the last granularity period 
shall be indicated in the file name. 

The file shall be made available for transfer to or collection by the NM as soon as all applicable results have been 
assembled. 

5.1.2 File naming 

The following convention shall be applied for measurement result file naming: 
<Type><Startdate>.<Starttime>-[<Enddate>.]<Endtime>[_-<jobId>][_<UniqueId>][_-_<RC>] 

1) The Type field indicates if the file contains measurement results for single or multiple NEs and/or granularity 
periods where: 

"A" means single NE, single granularity period; ( this is used when granularity period is equal to reporting 
period ) 

"B" indicates multiple NEs, single granularity period; ( this is used when granularity period is equal to 
reporting period) 

"C" signifies single NE, multiple granularity periods; (this is used when reporting period is multiples of the 
granularity period and will contain multiple measurement reports ) 

"D" stands for multiple NEs, multiple granularity periods, (this is used when reporting period is multiples of 
the granularity period and will contain multiple measurement reports). 

2) The Startdate field indicates the date when the granularity period began if the Type field is set to A or B. If the 
Type field is either "C" or "D" then Startdate contains the date when the first granularity period of the 
measurement results contained in the file started. The Startdate field is of the form YYYYMMDD, where: 

- YYYY is the year in four-digit notation; 

- MM is the month in two digit notation (01 - 12); 

- DD is the day in two-digit notation (01 - 31). 

3) The Starttime field indicates the time when the granularity period began if the Type field is set to A or B. If the 
Type field is either "C" or "D" then Starttime contains the time when the first granularity period of the 
measurement results contained in the file began. The Starttime field is of the form HHMMshhmm, where: 

- HH is the two-digit hour of the day (local time), based on 24-hour clock (00 - 23); 

- MM is the two digit minute of the hour (local time), possible values are 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 
50, and 55; 

s is the sign of the local time differential from UTC (+ or -), in case the time differential to UTC is then the 
sign may be arbitrarily set to "+" or "-"; 

hh is the two-digit number of hours of the local time differential from UTC (00-23); 

- mm is the two digit number of minutes of the local time differential from UTC (00-59). 

4) The Enddate field shall only be included if the Type field is set to "C" or "D", i.e. measurement results for 
multiple granularity periods are contained in the file. It identifies the date when the last granularity period of 
these measurements ended, and its structure corresponds to the Startdate field. 

5) The Endtime field indicates the time when the granularity period ended if the Type field is set to A or B. If the 
Type field is either "C" or "D" then Endtime contains the time when the last granularity period of the 
measurement results contained in the file ended. Its structure corresponds to the Starttime field, however, the 
allowed values for the minute of the hour are 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, and 00. 

6) Uniqueld. This is the name of the NE, EM or domain, as defined in clauses 5.1.1.1 and 5.1.1.2 (e.g. a 
distinguishedName). The field may be omitted only if the distinguishedName is not available from the CM 
applications. 
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7) The RC parameter is a running count, starting with the value of "1", and shall be appended only if the filename is 
otherwise not unique, i.e. more than one file is generated and all other parameters of the file name are identical. 
Therefore it may only be used by the EM, since the described situation cannot occur with NE generated files. 
Note that the delimiter for this field, _-_, is an underscore character (_), followed by a minus character (-), 
followed by an underscore character (_). 

8) jobld. When PMIRP is supported, the jobid shall be indicated in the performance measurement file name. 
Some examples describing file-naming convention: 

1) file name: A20000626.2315+0200-2330+0200_NodeBId, 

meaning: file produced by NodeB <NodeBId> on June 26, 2000, granularity period 15 minutes from 23:15 local 
to 23:30 local, with a time differential of +2 hours against UTC. 

2) file name: B20021224.1700-1 130-1705-1 130_-joblO_EMId, 

meaning: file containing results for multiple NEs, generated for measurement job job 10, produced by EM 
<EMId> on December 24, 2002, granularity period 5 minutes from 17:00 local to 17:05 local, with a time 
differential of -1 1 :30 hours against UTC. 

3) file name: D20050907. 1030+0000-20050909. 1500+0000_DomainId_-_2, 

meaning: file containing results for NEs belonging to domain <DomainId>, start of first granularity period 07 
September 2005, 10:30 local, end of last granularity period 09 September 2005, 15:00 local, with a time 
differential of against UTC. This file is produced by the EM managing the domain, and it is the second file for 
this domain/granularity period combination. 

4) filename: C20050907. 1030+0000-20050909. 1500+0000_NodeId, 

meaning: file produced by the Node <NodeId> , start of first granularity period 07 September 2005, 10:30 local, 
end of last granularity period 09 September 2005, 15:00 local, with a time differential of against UTC. 



5.2 File transfer procedure 



Both push (i.e. triggered by the NE) and pull (triggered by the OS) transfer modes shall be supported on the NM 
interface. Implementation specific means may be employed for the administration and control of the file transfer, 
concerning: 

- the time of the transfer (in push mode); 

- the routing of the transfer to one or more OS(s) (in push mode); 

- the storage/deletion of the files in the NE, particularly when the EM based approach is chosen (cf . 
clause 5.1.1.2). 

Measurement result files shall be retained by the file generator (i.e. NE or EM) at least until they have been successfully 
transferred to or collected by the NM. The storage capacity and the duration for which the data can be retained at the 
NE or the EM will be Operator and implementation dependent. 

The file transfer procedure implemented in the system (NE or EM) shall ensure that no data can get lost under normal 
operating conditions. The procedure shall also ensure that the files will be deleted after successful transfer to the NM. 
Depending on the exact implementation of the procedure, the NM may be responsible for deleting those files, or older 
files will be eventually overwritten by new ones by the file generator in a round robin fashion. 

Each implementation shall support all primitives of the selected protocol (e.g. put file, get file, inspect directory 
contents, delete file) which are needed by the NM. These primitives depend on the details of the procedure, as defined 
by the manufacturer. 
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Annex A (informative): 

The table oriented file format structure 

Measurement Items (counters) are typically grouped according functionality (cf. 3GPP TS 52.402 [7] Measurement 
Function). The term "measured object class" is used to identify such a group. The file format is based on the fact that 
the measurements are always collected in sets of one functional group. 

The measlnfo contains the sequence of measurements, values and related information, in a table-oriented structure. 
It includes a list of measurement types ("measTypes") and the corresponding values ("meas Values"), together with the 
time stamp ("measTimeStamp"), granularity period ("granularityPeriod") and reporting period ("reportingPeriod") 
pertaining to these measurements. Whenever one of these 4 elements changes, then a new measlnfo sequence is started. 
If the "measTypes" change, then also the "meas Values" change, because these elements are connected in the following 
way: the "measTypes" correspond to a specific measurement object (NE, trunk, cell, . . .), of which one or more 
instances can exist inside the NE. 

Hence for one set of "measTypes", there can be one or more sets of "meas Values", according to the "measObjInstId". 

The above is best explained with an example: consider the CELL measurement function (3GPP TS 52.402 [7]). Then 
the measured object class is Cell. The measlnfo contains a "header" line defining which measurements related to Cell 
are collected (measTypes), and in which order. The subsequent "data" lines will then contain the values of the 
measurements for each specific cell, which is measured, one data line per cell (meas Values). 

This format will generate a kind of table with as column headings the measurement names, and in the rows the 
corresponding measurement values per measured instance. 



A.1 Graphical representation of the table structure 

For clarity, the table in the example below only contains the measTypes and meas Values (and suspectFlag), not the 
granularityPeriod, reportingPeriod and the measTimeStamp. 





attTCHSeizures 


succTCHSeizures 


attlmmediateAssignProcs 


succlmmediateAssignProcs 




cell=997 


234 


345 


567 


789 


false 


cell=998 


890 


901 


123 


234 


false 


cell=999 


456 


567 


678 


789 


false 
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Annex B (informative): 
Change history 
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